The well-known Ethernet protocol (IEEE 802.3) provides a method of transmitting data packets over a local area network. Ethernet packets are transmitted on a cable without pre-arranged scheduling, such that collisions may occur on the cable. The protocol includes mechanisms for detecting collisions and retransmitting packets that fail to reach their destination due to a collision. Bridges between networks allow packets to be further transmitted between nodes residing on different networks (see FIG. 4). Each data packet, referred to as a “frame” in Ethernet parlance, conforms to a well-known standard including 6-byte (48-bit) source and destination addresses embedded in a 14-octet frame header.
Each Ethernet address, referred to more generally as a Media Access Control (MAC) address, must be unique on a network in order to ensure that a given packet will arrive at the correct destination. In practice, companies that make Ethernet network cards register MAC addresses with a central authority (e.g., the IEEE) to ensure that the address of each card will be unique across all networks and will not conflict with the addresses used by any other card, even if made by a different manufacturer. Consequently, it can be assured that Ethernet nodes on different networks connected by a bridge will not have the same MAC address.
It is conventional to transmit Internet Protocol (IP) packets, which rely on a different format and addressing scheme, over an Ethernet. As is conventional, IP data packets are “encapsulated” in an Ethernet frame, transmitted over an Ethernet LAN, and “unwrapped” at the receiving node to restore the original IP packet.
FIG. 2 shows a conventional system in which IP packets are transmitted between two nodes 200 and 250 over an Ethernet LAN. Application programs on each node (201 and 251) communicate with each other using TCP/IP protocols 202 and 252, respectively. As part of this process, an Address Resolution Protocol (ARP) 203 and 253 is used in each Ethernet node to translate 32-bit IP addresses into 48-bit MAC addresses and vice versa.
For example, when a transmitting Ethernet node transmits an IP packet to a destination IP address, the ARP protocol in the transmitting node determines the corresponding MAC address for the destination node based on the IP address, typically using a look-up table. This MAC address, along with the MAC address of the transmitting node, is stored into an Ethernet frame header, and the IP packet (including its own IP packet header) is “wrapped” into the Ethernet frame and transmitted over the network.
FIG. 3 shows the general encapsulation scheme, illustrating how an IP packet, which has its own IP source and destination addresses, is encapsulated in an Ethernet frame having Ethernet (MAC) source and destination addresses.
ARP works by broadcasting a packet containing the IP address with which the transmitting node is interested in communicating to all nodes attached to an Ethernet. Most nodes ignore the broadcast, but the ARP in the destination node responds upon recognizing that the IP address in the packet matches its own. The destination node responds with a message indicating its MAC address, which the transmitting node then uses to transmit the packet. Each node typically maintains a cache of ARP responses on the assumption that address mappings rarely change. As shown in FIG. 4, ARP also works across bridged networks, since ARP broadcasts are received by bridges that then pass them on to nodes on the bridged networks. Consequently, ARP responses may arrive from networks other than the LAN on which the transmitting node resides.
Recently, a serial bus standard known as the IEEE 1394 bus has been developed. Implementations of this bus are based on the internationally adopted ISO/IEC 13213 (ANSI/IEE 1212) CSR Architecture Specification and the IEEE 1394-1995 Serial Bus Specification, which are publicly available documents. A typical system conforming to the IEEE 1394 standard includes a plurality of nodes that are interconnected via point-to-point links, such as cables, that each connect a single node of the serial bus to another node of the serial bus. The nodes are addressable entities that can be independently reset and identified. The 1394 bus provides both asynchronous and isochronous (time-guaranteed delivery) capabilities. The IEEE 1394 bus standard requires that each node have a 64-bit unique node identifier, which permanently identifies the node throughout its life, independent from other nodes or events on the serial bus.
Given the numerous capabilities and low cost of the IEEE 1394 bus, it is anticipated that computer systems that previously relied on Ethernet to implement network communication will be modified to use the newer IEEE 1394 bus, and/or to co-exist with the 1394 bus. A large amount of software written specifically for Ethernet and IP over Ethernet will need to be rewritten to operate using the 1394 bus, thus imposing costs and schedule delays. Consequently, one challenge arising out of moving to the newer 1394 bus implementation is figuring out how to minimize the costs associated with migrating Ethernet-based systems to a 1394-based implementation.
Various implementations of the IEEE 1394 bus in computer systems typically include layered hardware and software support based on transaction, link, and physical layer protocols. The publicly available IETF Request for Comments (RFC) 2734 describes a scheme for using the 1394 bus to transmit IP datagrams. The document generally refers to transmitting specific IP flows over isochronous channels of the IEEE 1394 bus. However, it does not suggest emulating Ethernet functionality using the IEEE 1394 bus.
A company known as Unibrain has advertised a proprietary Ethernet software emulation product, referred to as FireNet™, which purportedly emulates unique Ethernet addresses by setting Ethernet addresses to be based on the IEEE-1394 address that was assigned to the IEEE-1394 board.
One problem that arises when considering the use of an IEEE 1394 serial bus to emulate Ethernet functionality relates to packet sizes. Maximum Ethernet packet sizes are fixed at about 1500 bytes, while packet sizes on the 1394 bus can vary depending on node capabilities. Certain 1394 bus nodes may have the capability of transmitting and receiving at one data rate (e.g., bytes per second), while others may only be able to communicate using lower rates. Various tradeoffs relating to packet sizes and bus speeds give rise to a more general problem: how to translate Ethernet frame sizes into the various packet sizes that can be accommodated by 1394 bus nodes.
In summary, it would be desirable to emulate Ethernet functionality over an IEEE 1394 serial bus, so that existing software already written for Ethernet interfaces can readily used without major revisions. Moreover, it would be desirable to emulate Ethernet functionality in a manner that takes advantage of various 1394 capabilities in an efficient manner.